1. Field of the Invention
The present invention relates to computer networks and in particular to handling client requests in systems having multiple servers.
2. Description of Related Art
On computer networks, nodes may interact through requests for data, services, or other resources. Client nodes may generate requests and server nodes may service those requests. Nodes may be stand-alone computers, servers, or other computing devices, as well as virtual machines, threads, processes, or other network participants. To handle a greater volume of requests, a plurality of servers may be allocated to responding to one or more types of requests and the servers as a group may be referred to as a server farm. For example, a bank, ticket office, or some other organization may use a server farm to process requests from clients. The servers may be web servers on the Internet responding to web clients.
To provide coherent service to clients, state or session information may be collected and used by servers, so that their response to a given client may depend on session data for the client in the server farm. For example, session information may be used to implement a “shopping cart” used across multiple requests over one or more servers. It may be more efficient to store the session information on a single server within the server farm, rather than disperse that information, and ensure that the corresponding server services the requests from the associated client.
A typical system may have a unique session ID assigned to correspond to collected client session information. Initially, requests do not contain session IDs since there is not yet a session formed with the server farm. The first server to receive a request from a given client typically generates the session ID. After a server creates a session for a client, the server generates a session ID to uniquely represent that session, and instructs the client to return the generated session ID in subsequent requests from that client. For example, a session ID may be encoded in the URLs the client is instructed to access or it may be stored in a server-generated cookie the client is instructed to send back to the server with each request.
Requests may be routed between the clients and the servers through one or more devices, which may be considered upstream from the servers and downstream from the clients. These devices may be part of the server farm or may operate within the network or other system. For example, the server farm may include one or more routers that receive the requests from the network and route them to servers.
The work that a server performs processing requests it receives is referred to as the load of that server. Depending on the allocation of requests and the processing required, the load may differ widely between servers and limit performance. Another example of upstream devices is load balancers. In order to distribute load across a plurality of servers within a server farm, load balancers may be used. Load balancers may be additional devices, may be part of other devices, or may include other functionality. For example, load balancers may receive incoming requests to the server farm and route the requests to individual servers in addition to determining where requests may be sent to better balance loads in the server farm.
In some systems, a load balancer or other device may be configured to receive incoming requests, examine them for a session ID, and then route them to the server that generated the session ID so that session information is kept on a single server within the server farm. The technique of using the session ID to select the server that will service a given request is called “sticky sessions”, “sticky load balancing”, or “sticky routing” since the presence of a session ID causes the requests associated with that session to “stick” to a specific server.
Some systems may include load balancers or other devices in the server farm that receive requests and send them to servers. These devices may maintain a mapping of session IDs to servers. These devices may then compare the session IDs with the requests to their mapping information to find the corresponding server. However, the size of the data for the mapping may be prohibitive as there may be many session IDs—at least one per client of the server farm.
In some systems, servers may provide their address, such as an Internet hostname or address, to clients so that the client or devices within the server farm, such as load balancers, may use that information to route subsequent requests using standard Internet routing protocols to the corresponding server. However, exposing the server addresses or other details of the sever farm configuration communicates information about the internal arrangement of the server farm to the client or others outside the server farm. As the client is typically a distrusted third party, exposing information about the internal operation of the server farm may be a security risk.
Alternatively, an administrator may configure a load balancer and servers with a particular ID corresponding to each server as identifying information. Servers may then include this identifying information in their session ID without revealing information about the internal structure of the server farm. However, the load balancer and server must then share data that allows the load balancer to target a specific server from the identifying information. This implementation imposes a burden on server farm administrators, as configuration information for these session IDs is then maintained for all load balancers and servers.